Some computing applications consume files conforming to the Open Packaging Convention. These files, often called “packages,” may enable these applications to open particular documents, such as a particular word-processing application consuming a particular package to open a particular word-processing document.
Each of these computing applications may require its packages to have a particular package structure in addition to conforming to the Open Packaging Convention (OPC). An instance of a package that does not conform to a computing application's needed structure may cause the application to fail in some way. For example, if a spreadsheet application attempts to open a particular spreadsheet document by consuming a package that does not conform to that spreadsheet application's required structure, the application may not be able to open the document or may encounter some other problem.
To address this issue, package drafters may refer to a human-readable specification of the structure needed by a computing application for which they intend to build packages. The drafters may then build each package based on the human-readable specification in an attempt to enable the computing application to consume each package without failure. Drafters, however, may fail to correctly structure packages.
A drafter may attempt to find structural failures in a package by consuming the package with the appropriate computing application in the hope that if the package does not have the proper structure it will fail in a discernable manner. If it does, the drafter may then attempt to determine the cause of the failure and address it. But consuming packages in the hope that by trial-and-error a structural defect may cause a discernable failure is both time consuming and unreliable. When this trial-and-error process fails to find an existing structural defect, packages having this structural defect may be distributed to users and cause extensive downstream problems.